4.3. Planung von Iterationen und Sprints
Nachdem wir die agilen Frameworks Scrum und Kanban kennengelernt haben, widmen wir uns nun dem Herzstück der agilen Umsetzung: der Planung von Iterationen, in Scrum Sprints genannt. Die Sprint-Planung ist das Ereignis, das den Rhythmus für die gesamte Entwicklungsarbeit vorgibt. Hier verpflichtet sich das Team auf ein erreichbares Ziel für den kommenden Zyklus.
Stellen Sie sich vor, Sie bereiten sich auf eine Bergtour vor, die aus mehreren Etappen besteht. Die Sprint-Planung ist die Besprechung am Morgen vor jeder Etappe. Das Team schaut auf die Gesamtkarte (das Product Backlog), entscheidet, welches Zwischenziel (das Sprint-Ziel) heute erreicht werden soll, und plant die genaue Route und die notwendigen Aufgaben, um dieses Ziel zu erreichen.
Der Ablauf des Sprint Plannings
Das Sprint Planning ist ein zeitlich begrenztes Meeting (typischerweise maximal 8 Stunden für einen einmonatigen Sprint), das zu Beginn jedes Sprints stattfindet und zwei zentrale Fragen beantwortet:
- Was kann in diesem Sprint geliefert werden?
- Wie wird die ausgewählte Arbeit erledigt?
Teil 1: Das "Was" – Sprint-Ziel und Backlog-Auswahl
- Input: Der Product Owner kommt mit einem priorisierten Product Backlog in das Meeting. Er erläutert die wichtigsten Einträge (meist User Stories) und beantwortet Fragen des Entwicklungsteams, um sicherzustellen, dass alle das gleiche Verständnis haben.
- Diskussion: Das gesamte Scrum-Team (Product Owner, Scrum Master, Entwicklungsteam) diskutiert die Ziele und die Umsetzbarkeit.
- Ergebnis: Das Team formuliert ein Sprint-Ziel (Sprint Goal). Dies ist ein kurzer Satz, der beschreibt, was der Sprint zu erreichen versucht und warum er für die Stakeholder wertvoll ist. Anschließend wählt das Entwicklungsteam die Anzahl der Product-Backlog-Einträge aus, die es für realistisch hält, um dieses Ziel zu erreichen.
Teil 2: Das "Wie" – Die Umsetzung planen
- Input: Die vom Team ausgewählten Backlog-Einträge.
- Aktivität: Das Entwicklungsteam zerlegt die ausgewählten User Stories in kleinere, konkrete technische Aufgaben (Tasks). Diese Aufgaben sind oft nur einen Tag oder weniger lang.
- Ergebnis: Das Sprint Backlog. Es besteht aus dem Sprint-Ziel, den ausgewählten Product-Backlog-Einträgen und dem Plan zur Umsetzung (den heruntergebrochenen Tasks). Das Sprint Backlog ist der Plan des Entwicklungsteams für den Sprint.
Schätzung des Aufwands: Story Points und Planning Poker
Um eine fundierte Auswahl für den Sprint treffen zu können, muss das Team den Aufwand der Product-Backlog-Einträge schätzen. In agilen Teams wird Aufwand selten in Stunden oder Tagen geschätzt, sondern in abstrakten Einheiten, den Story Points.
💡 Merksatz: Planning Poker fördert die Diskussion und stellt sicher, dass das Wissen aller Teammitglieder in die Schätzung einfließt. Es geht nicht darum, eine "perfekte" Zahl zu finden, sondern ein gemeinsames Verständnis für die Aufgabe zu entwickeln.
Der Einfluss der Systemarchitektur auf die Sprint-Planung
Die Planung eines Sprints findet nicht im luftleeren Raum statt. Eine der wichtigsten Randbedingungen ist die bereits existierende oder geplante System- und Software-Architektur.
Stellen Sie sich vor, Sie planen den Innenausbau eines Raumes. Ihre Planung hängt maßgeblich davon ab, ob die tragenden Wände, die Elektrik und die Wasseranschlüsse (die Architektur) bereits vorhanden und wie sie beschaffen sind.
- Architektur als Leitplanke: Die gewählte Architektur gibt vor, welche Aufgaben überhaupt möglich sind und wie komplex sie werden. Wenn die Architektur beispielsweise auf Microservices basiert, ist das Hinzufügen eines neuen, unabhängigen Features einfacher zu planen als in einer eng gekoppelten monolithischen Anwendung.
- Architektur als Teil der Arbeit: Besonders in frühen Sprints können Aufgaben darin bestehen, die Architektur selbst erst aufzubauen oder zu erweitern (sog. "Enabler Stories" oder "Spikes"). Eine Aufgabe im Sprint Backlog könnte lauten: "Datenbankschema für die Benutzerverwaltung entwerfen" oder "Schnittstelle zum Bezahldienstleister recherchieren und anbinden".
- Abhängigkeiten aufdecken: Die Architektur beeinflusst, welche Abhängigkeiten zwischen Aufgaben bestehen. Die Planung muss dies berücksichtigen. Mit einem API‑First‑Ansatz (siehe Kapitel 5.5.3) verschiebt sich die Abhängigkeit von der Backend-Implementierung auf den vereinbarten Vertrag (z. B. OpenAPI). Die Arbeit am Frontend kann beginnen, sobald eine stabile API-Spezifikation und ein Mock/Stub verfügbar sind; die Backend‑Implementierung (inkl. Persistenz) kann parallel erfolgen. Vertragstests (z. B. Consumer‑Driven Contracts) stellen sicher, dass beide Seiten kompatibel bleiben.
⚠️ Achtung: In der agilen Welt wird Architektur oft als "emergent" (entstehend) betrachtet. Man entwirft nicht die gesamte Architektur für Jahre im Voraus, sondern beginnt mit einer minimalen, aber soliden Basis ("Walking Skeleton") und lässt sie mit jeder Iteration wachsen. Dennoch müssen grundlegende Architekturentscheidungen früh getroffen werden, da sie weitreichende Folgen haben. Wie man solche Architekturen entwirft und welche Muster es gibt, wird detailliert im nachfolgenden Kapitel 5 "Systementwurf und Architektur" behandelt.
Hybride Einflüsse auf das Sprint Planning (Kanban + XP)
Wenn Teams Scrum mit Kanban und XP kombinieren, verändert sich die Sprint-Planung an einigen Stellen spürbar – ohne den Scrum-Rahmen zu verlassen.
Kanban-Aspekte im Sprint Planning
- WIP-Grenzen berücksichtigen: Bei der Auswahl der Stories darauf achten, dass die geplanten Tasks die WIP-Limits der Prozessschritte (z. B. Development, Review, Test) nicht sprengen.
- Flow-orientierte Reihenfolge: Stories so sortieren, dass Engpässe (z. B. Testkapazität) geglättet werden; lieber wenige parallel starten, früh fertigstellen.
- Option für dringende Arbeit: Ein kleines Kapazitäts-Pufferfenster (z. B. 10–15%) explizit einplanen, falls dringende Tickets in den Sprint gezogen werden müssen – WIP-Limits schützen trotzdem den Fluss.
- Service-Klassen klären: Falls genutzt, vereinbaren, wie Expedite/Fixed-Date-Items den Sprint beeinflussen (klare Definition, Timeboxing, Trade-offs).
XP-Aspekte im Sprint Planning
- Qualität einplanen: Tests, Refactoring, Pairing sind Teil der Schätzung und der Tasks – nicht „nice to have“.
- TDD/ATDD vorbereiten: Beispiele/Akzeptanzkriterien im Refinement klären; im Planning Tasks für Testfälle und Testdaten ergänzen.
- Pair-/Mob-Slots planen: Sichtbare Pairing-Zeiten und Rotationen eintragen, damit Verfügbarkeit realistisch ist.
- CI/CD-Constraints: Build-/Testzeiten berücksichtigen (z. B. kurze Batch-Größen, Feature-Flags), um kontinuierliche Integration sicherzustellen.
Praktische Anpassungen an Teil 1 (Was) und Teil 2 (Wie)
- Teil 1 – Was: Sprint-Ziel so formulieren, dass Flow-Messpunkte (z. B. „zwei Stories bis Mitte des Sprints done“) sinnvoll sind; Kapazität für Quality-Work explizit reservieren.
- Teil 2 – Wie: Tasks vertikal entlang des Flows schneiden (Design → Code → Test → Review → Done) und mit WIP-Limits abgleichen; technische Tasks für Tests/Refactoring/Automatisierung anlegen.
Kompakte Checkliste für hybrides Sprint Planning
- Sprint-Ziel ist klar, messbar und nicht durch WIP-Limits gefährdet.
- Stories sind vertikal geschnitten; keine überfrachteten, parallelen Bausteine.
- WIP-Limits und Engpässe im Plan berücksichtigt; kleiner Notfall-Puffer definiert.
- Tests (TDD/ATDD), Refactoring, Pairing als Tasks im Sprint Backlog enthalten.
- CI/CD-Rahmen eingeplant (kleine Batches, Feature-Flags, kurze Build-/Testzeiten).
Typische Stolpersteine und Gegenmittel
- Zu viel parallel: WIP-Limits missachtet → weniger Stories committen, Fokus auf Finish.
- Qualität „vergessen“: DoD pocht auf Tests/Refactoring; Quality-Tasks sichtbar planen.
- Ungeplante Tickets sprengen den Sprint: kleinen Puffer vorsehen, Pull-Regeln befolgen.
- Lange-lived Branches: Trunk-Based Development mit Feature-Flags; kleine PRs im Plan vorsehen.